SQL Server 2008 : Database Mirroring

The technique of database mirroring can be summed up very simply: It's the practice of keeping two separate copies of your database in synchronization with each other so that if you lose one copy, you can continue work with the other. Mirroring is commonly used at the disk level in RAID arrays. The concept is much the same when it comes to databases.

1. Key Terms

Just as failover clustering has its own terminology, database mirroring has its own conventions that you need to be familiar with. Study the list to follow because some of the same terms are used in other aspects of information technology, but with slightly different meanings. Using the correct terminology for SQL Server will help make sure everyone has the same understanding when discussing high availability. The key terms to be familiar with include the following:

• Principal: Source server containing the functionally active database in the mirrored pair.

• Mirror: Target server containing the destination database in the mirrored pair.

• Witness: Optional server that monitors the principal and mirror servers.

• Partner: Opposite server when referring to the principal and mirror servers.

• Endpoint: Object that is bound to a network protocol that allows SQL Servers to communicate across the network.

2. Database Mirroring Overview

Database mirroring was introduced in SQL Server 2005 and provides two levels of protection: high-performance mode and high-safety mode. Both modes have the same concept, but the order in which a transaction is committed is slightly different. With high-performance mode, the transaction is committed on the principal server before the mirror. This enables the application to move forward without having to wait for the transaction to commit on the mirror. With high-safety mode, the transaction is committed on the mirror before committing on the principal. This causes the application to wait until the transaction has been committed on both servers before moving forward. Both high-performance and high-safety modes require the principal database to be set to full recovery. We will look at each mode individually and discuss the pros and cons of using each technique.

2.1. Implementation

Database mirroring has a much easier implementation process when compared to failover clustering. It requires no special hardware configuration and can be applied and managed completely through SQL Server. Here are the basic steps you must perform in order to set up database mirroring:

One of the downsides of database mirroring compared to failover clustering is that you must set up database mirroring for each database, whereas once you set up failover clustering, the entire instance is protected. Since mirroring is configured for each individual database, you must make sure that any external data needed by the mirror database is also copied to the mirror server. For example, you need to copy logins from the master database to the master database on the mirror server, and also make sure that any jobs needed by the mirror database are on the mirror server. Also, since database mirroring makes a copy of the database, you will need to use twice as much disk space than you would with failover clustering. On the upside, having a duplicate copy of the database makes database mirroring a far better solution than failover clustering when you are worried about disaster recovery and disk failure. SQL Server 2008 even includes a new feature that will repair corrupt data pages by copying them from the partner once the corruption has been detected.

2.2. Snapshots for Reporting

In order to use a mirrored database as a reporting solution, you must also use the database snapshot feature, which requires the Enterprise Edition of SQL Server 2008. You can use database snapshots in conjunction with database mirroring in order to provide a static reporting solution by taking regular snapshots of the mirror database. Users are unable to connect directly to the mirror database to perform queries, but you can create a snapshot of the mirror database at any given time, which will allow users to connect to the snapshot database.

The snapshot database starts out relatively small, but as changes are made to the mirror database, the original data pages are added to the snapshot database in order to provide the data as it appeared when the snapshot was created. After some time of copying the original data pages, the snapshot database could become rather large, but never larger than the size of the original database at the time the snapshot was created. In order to keep the data current and the size of the snapshot to a minimum, you should refresh the snapshot periodically by creating a new snapshot and directing the traffic there. Then you can delete the old snapshot as soon as all the open transactions have completed. The snapshot database will continue to function after a failover has occurred; you will just lose connectivity during the failover while the databases are restarted. A failover could, however, place an additional load on the production system. Since it is now being used for processing the data for the application and serving up reporting requests, you may need to drop the snapshots and suspend reporting until another server is brought online.

2.3. Redirection in the Event of a Failure

Transparent client redirect is a feature provided in the Microsoft Data Access Components (MDAC) that works with database mirroring to allow client applications to automatically redirect in the case of a failover. When connecting to a database that participates in database mirroring, MDAC will recognize there is a mirror database and store the connection information needed to connect to the mirror database, along with the principal database. If a connection to the principal database fails, the application will try to reconnect. If the application is unable to reconnect to the principal database, a connection to the mirror database is attempted. There is one major caveat when working with transparent client redirect: The application must connect to the principal database before a failover has occurred in order to receive the connection information about the mirror. If the application cannot connect to the principal server, it will never be redirected to the mirror, meaning the failure must occur during an active application session. This can be mediated by storing two possible connection strings in the application.

3. High-Safety Mode

You can use high-safety mode in database mirroring to provide a duplicate copy of the principal database on a mirror server in a synchronous fashion so there is no chance of data loss between the principal and the mirror. In order for a transaction to commit on the principal database, it must first commit on the mirror. High-safety mode is supported in the Enterprise and Standard Editions of SQL Server, with one caveat being that the principal and the mirror must be running the same edition.

In order to provide the highest level of availability, you can use a witness server to verify connectivity between the principal and the mirror (see Figure 1). The witness server is not a requirement for high-safety mode, but it is a requirement for automatic failover capabilities. The witness server runs an instance of SQL Server that consumes very little resources and can even run using SQL Server Workgroup and Express Editions. Using a witness provides a communication check between the principal and the mirror, similar to the heartbeat in failover clustering. This communication check provides the ability for the mirror to assume the role of the principal should the principal become unavailable. The witness is not a single point of failure and does not actually perform the failover; it just provides verification to the mirror server that the principal server is down. If the witness server crashes, database mirroring is still operational and completely functioning between the principal and the mirror, and you will just lose the ability to automatically fail over. The reason for this behavior is to prevent unnecessary failovers due to network connectivity. In order for a server to become a principal server, it has to be able to communicate with at least one other server; therefore, the only purpose of the witness is to answer the question, "Is the principal down?" In order to automatically recover from a failure, the witness and the mirror servers must agree that the principal is actually down.

Figure 1. Database mirroring high-safety mode with witness server

4. High-Performance Mode

You can use high-performance mode in database mirroring to perform asynchronous operations between the principal and mirror databases. High-performance mode supports only a manual failover with the possibility of data loss. There is no need to use a witness server in high-performance mode because there is no automatic failover capability. Since the principal database does not have to wait for acknowledgment from the mirror server in order to keep processing requests, high-performance mode could increase application performance if you have a slow network connection or latency issues between the principal and mirror servers. Asynchronous processing also means that the mirror server can be several minutes behind when processing a high volume of transactions, which may or may not be acceptable, depending on the requirements agreed upon in the SLA. High-performance mode is only supported if you are using the Enterprise Edition of SQL Server.

Figure 2 shows the typical configuration of database mirroring using high performance mode. Notice the order of operations using high performance mode that allows the application to perform requests without having to wait for the transactions to commit on the mirror.

Figure 2. Database mirroring high-performance mode

5. Pros and Cons of Database Mirroring

As always, there are trade-offs to think about. The benefits of database mirroring include the following:

• No special hardware or windows configurations

• No distance limitations

• Duplicate data for disaster recovery

• Possible reporting solution using database snapshots of the mirror

Following are some restrictions and drawbacks of database mirroring to be aware of:

• Requires more disk space to store duplicate data

• Must be configured separately for each database

• May cause application performance issues on slow networks (high-performance mode)

In addition, keep in mind the following differences between high-safety mode and high-performance mode:

• High-safety mode ensures zero data loss. High-performance mode trades the chance of some data loss for increased performance.

• High-safety mode can cause application performance issues on slower networks. High-performance mode avoids performance issues by not waiting for the mirror to commit first (hence, the risk of data loss).

• Recovery is faster in high-safety mode because no uncommitted transactions need to be applied or undone.

• For the same reason, failover can be automatic in high-safety mode, but not in high-performance mode.